On the question of filtering on AlgorithmType vs AlgorithmDescription, the way I see it is this. Neither field has been formally specified to us as having stable values so there are, in principle, two failures modes:

1. we try to return EFI results but something has changed and we don't return any results;
2. we try to return EFI results but something has changed and we return the wrong results.

Of the two, it seems to me that 1 is far more preferable. It's likely to be noticed immediately by the researcher, and even if it isn't missing values are likely to be overall less harmful than incorrect values. And filtering by the description is, I think, far more likely to fail in first way whereas filtering by the type number runs a greater risk of failing in the second way. That is, it's very unlikely that the string "UK Electronic Frailty Index (eFI)" will refer to anything other than the thing we want. But it's not inconceivable that "Algorithm Type 1" might do.

In fact, I might be minded to not expose AlgorithmType at all to users just to avoid the risk that they start relying on it.

On the question of what the values are, we have now included these in the TPP database schema reports we generate. However, I don't think we've yet re-run the report. And we haven't included it in the set of things we automatically fetch and include in the ehrQL repo. We should do that.